\section{Conclusiones}

%% Quedó algún chamuyo sin usar? Mandar aca!
%% Puede no estar, pendiente de revisión.

Al realizar el trabajo práctico descubrimos que lo que a simple vista parecía
relativamente claro y conciso (en particular al leer el enunciado por primera
vez), escondía en realidad muchas ambigüedades o decisiones que debíamos tomar
por nuestra cuenta o al menos aclarar con el cliente. En el mundo real, esto parecería indicar que un único
relevamiento de requerimientos no suele ser suficiente: hace falta un contacto
directo con el cliente para aclarar las dudas que vayan surgiendo a medida que
se arma la especificación más formal. 

A los integrantes que no trabajamos en la industria nos resultó interesante
descubrir que en general los requerimientos de software se plantean más como el
enunciado de este TP y menos como especificaciones formales. Esto nos ayudó a
darnos cuenta de la importancia del proceso de especificación, y en particular
de la creación de diagramas para entender y comunicar entre las partes los objetivos y el contexto
de una pieza de software. Por mucho que queramos especificaciones perfectas
para facilitar la implementación, los clientes expresan sus deseos en lenguaje informal y aplicado
al contexto en el que se manejan profesionalmente, pudiendo tomar como triviales
cosas que a los programadores no les son así.

A su vez, nos incitó a pensar y tener en cuenta alternativas (y plasmarlas en
el análisis) para cuando las condiciones que no podemos manejar no son las
ideales (en particular con la posibilidad de que no haya Internet, y cómo responde nuestro
sistema en ese caso). Descubrimos que es una buena práctica tener en cuenta este tipo 
de cuestiones, ya que las cosas no siempre ocurren como uno espera y un software que puede adaptarse a
eso tiene ventaja frente a uno que no.

Por último, también nos ayudó a darnos cuenta de que en muchas situaciones
hay que encontrar un equilibrio entre eficiencia de una solución y su costo, y
que en general conviene listar varias alternativas como propuestas
distintas para que el cliente elija según su conveniencia. Creemos que esto resulta fundamental
a la hora de desarrollar tecnología para un tercero; sus valores, prioridades y necesidades
nos son ajenas completamente. La comunicación a través de charlas y diagramas claros disminuye
la distancia entre el mundo de las ideas y el de la implementación, pero siempre tenemos que tener 
en cuenta que en el fondo el único que sabe lo que quiere o al menos puede decidir si algo le
parece correcto o incorrecto, es el cliente.